A Contract-Based Approach to Ensuring Component Interoperability in Event-B

constants and sets (types). Moreover, the interface MI itself may be parameterised with the constant id, which is used as an unique identifier for a module instance within the interface. All such data structures become module parameters that can be instantiated when a module is imported. The concrete values or constraints needed for module instantiation are supplied within the USES clause of the importing machine. Alternatively, the module interface can be extended with new sets, constants, and the properties that define new data structures and/or constrain the old ones. Such an extension produces a new, more concrete module interface. Via different instantiation of generic parameters the designers can easily accommodate the required variations when developing components with similar functionality. Hence module instantiation provides us with a powerful mechanism for reuse. We can create several instances of a given module and import them into the same machine. Different instances of a module operate on disjoint state spaces. Identifier prefixes can be supplied in the USES clause to distinguish the variables and operations of different module instances or those of the importing machine and the imported module. Alternatively, the pre-defined set can be supplied as an additional parameter. In the latter case, module instances are created for each element of the given set. The syntax of USES then becomes as follows: USES < module interface > as < prefix > or USES < module interface > [< constant set >]. Semantics of a Module Interface. Similarly to a machine component, the semantics of an interface component is defined by a number of proof obligations. The module initialisation must establish the module invariant M Inv: M Init(s, c,mv′) ` M Inv(s, c,mv′) (MOD INIT) Let us assume Oper i, i ∈ 1..N , is one of module operations. The module invariant M Inv should be preserved by each operation execution: M Inv(s, c,mv), Prei(s, c, p,mv), Posti(s, c, p,mv,mv ′, res) ` M Inv(s, c,mv′) (MOD INV1) where Prei and Posti are respectively the precondition and postcondition of Oper i. Let us assume Ev j , j ∈ 1..K, is one of module process events. The module invariant M Inv should be also preserved by each such event: M Inv(s, c,mv), BAj(s, c, lv,mv,mv ′) ` M Inv(s, c,mv′) (MOD INV2) where BAj is the before-after predicate of Ev j . Finally, there is a couple of feasibility proof obligations for each Oper i, i ∈ 10 From Action System to Distributed Systems: The Refinement Approach 1..N . Firstly, the operation precondition should be true for at least some of parameter values: M Inv(s, c,mv) ` ∃p. Prei(s, c, p,mv) (MOD PARS) Secondly, at least some operation post-state containing the required result must be reachable: M Inv(mv), P rei(p,mv) ` ∃(mv′, res). Posti(p,mv,mv, res) (MOD RES) Semantics of an Operation Call. A machine importing a module instance operates on the extended state consisting of its own variables v and the module variables mv. The module state can be updated in event actions only via operations calls. The semantics of an event containing an operation call is as follows. Let us consider the model event Ec that contains a call to the module operation Op with the given arguments args, i.e., it is of the form any lv where g then S[Op(args)] end. The BA predicate of such an event can be defined as follows: BAEc(s, c, v,mv, v ,mv) = ∃(lv, res, new mv). g(s, c, lv, v,mv) ∧ Post(sMI, cMI, args,mv, new mv, res) ∧ BAS∗ (s, c, lv, v,mv, res, v ) ∧ (mv = new mv), where S∗ is S with all the occurrences of Op(args) replaced by res, while sMI and cMI are respectively the sets and constants defined in the module interface context. Once this is done, we can rely on the existing proof semantics to verify the invariant preservation, event simulation and other required properties. Moreover, we need an additional proof obligation to ensure call correctness by checking that the operation precondition holds at the place of an operation call: g(s, c, lv, v,mv), Inv(s, c, v,mv), M Inv(sMI, cMI,mv) ` Pre(sMI, cMI, args,mv) (CALL CORR) The modularisation extension of Event-B facilitates formal development of complex systems by allowing the designers to decompose large specifications into separate components and verify system-level properties at the architectural level. Next we demonstrate how to define contracts based on the modularisation extension of Event-B. A Contract-Based Approach to Ensuring Component Interoperability in Event-B 11 COMPONENT CLASS C(id) EXTERNAL VARIABLES v